Subject: DLSW MIB

From: "David D. Chen ((919)-254-6182 8-444)" <[email-masked]>
Date: Wed, 21 Jun 95 09:45:04 EDT

Ref:  Note (attached)

Brian Jewell <[email-masked]> said:
>
>Everyone,
>
>Re: DLSW MIB...some comments and corrections:
>
>To illustrate some concerns about the dlswTConnOperTable, I enclose an excerpt
>from RFC 1212:
>
>
>   "In defining a conceptual row, it is useful to consider the
>    optimization of network management operations which will act upon its
>    columnar objects.  In particular, it is wisest to avoid defining more
>    columnar objects within a conceptual row, than can fit in a single
>    PDU.  As a rule of thumb, a conceptual row should contain no more
>    than approximately 20 objects.  Similarly, or as a way to abide by
>    the "20 object guideline", columnar objects should be grouped into
>    tables according to the expected grouping of network management
>    operations upon them.  As such, the content of conceptual rows should
>    reflect typical access scenarios, e.g., they should be organized
>    along functional lines such as one row for statistics and another row
>    for parameters, or along usage lines such as commonly-needed objects
>    versus rarely-needed objects."
>
>
>Is it possible that the size of a row in the dlswTConnOperTabletable might
>be considered excessive??

I am not sure if such a rule of thumb still is applicable.
sdlcLSStatsTable in SDLC MIB has 40 columnar objects.
Does anyone have an opinion?

>
>Also, has consideration been given as to the "overhead" of keeping all these
>counters (particularly "InDataOctets" and "OutDataOctets")? Overhead can
>be an important issue to router vendors.
>
>I suppose that the argument can be made that, from the standpoint of
>evaluating performance, this information is useful. But how much meaning
>will it have to a typical network administrator sitting at an NMS console?
>

What counters to keep has went through multiple scrutinizing.
>From what I can tell those counters are the ones people felt
are important for NMS to understand how the network is running.

>That's not to say that many of these objects shouldn't be included in the
>MIB...  But could the spirit of SNMP be better served if some of these
>objects were placed in a separate table (or preferably a separate group -
>as it is considered unacceptable to implement a "portion" of a group)? I would
>like to know if there are other opinions on this.
>

In SNMPv2 SMI, it is all up to the Compliance Statements.

>Also, by way of more mundane (and less controversial) comments, I have
>found the following errors in the MIB:
>
>1) A typo for the OID for the "dlswTConnOperPartnerSapList" (it is defined
>as a leaf of "dlswTConnOperResourceSnaEntry" in my copy of the MIB).
>
>2) Another typo: "dlswTConnOperEntry ::= SEQUENCE { ... " should begin with
>an uppercase 'D' (e.g. "DlswTConnOper..."). (This seems like a minor typo but
>it really caused my MIB compiler to go non-linear).
>
>3) "dlswTConnOperPartnerNBExcl" is specified as two conflicting types (INTEGER
>and TruthValue). The same error exists for the "dlswTConnOperPartnerMacExcl" object.
>

Thanks.  Dave

>Thanks.
>Brian Jewell
>3Com, Inc.